Re: [fpc-devel] property syntax extension
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 Description: MS-Word document ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
Op Wed, 17 Oct 2007, schreef Felipe Monteiro de Carvalho: Hello, I was reading about the difference between arm4 and thumb: http://wiki.forum.nokia.com/index.php/ARM4,_ARMI__THUMB Because I noted that all examples for Symbian OS use thumb and fpc supports only arm4. Acording to the nokia wiki using thumb would be produce smaller and faster code on the majority of mobiles, It is not that black and white. Some ARM processors use 16-bit busses and and therefore need 2 cycles to fetch normal 32-bit assembler instructions. On the other hand in thumb mode your instructions and adressing modes are much more limited, requiring you to write more instructions to do the job. 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 switching a switch when calling the assembler? No, thumb assembler code is different from generating normal assembler code. You need serious code generator modifications. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc-devel Digest, Vol 40, Issue 16
y
Op Tue, 16 Oct 2007, schreef L:
Functions like strtoint however have raise calls.
Yes, but there already exists a raise-less version of strtoint, called
val. So, there is IMO absolutely no need for an exceptionless version of
strtoint in another unit.
Of course we can use our own functions that emulate what is in the sysutils
unit.. but if they aren't drop in replacements this means that code is broken
and now we have to add Val calls and Str calls instead of just using a drop in
replacement.
The str() and val() functions I use occasionally, and I know turbopascal
programmers had to use them.. but they are not drop in replacements. One of
the
goals of compactsysutils was to be a drop in replacement. It is nice to be
able
to immediately convert a string to integer instead of using var params or OUT
params. There is a way to build a StrToInt that still reports errors.. it
returns a zero on error.
The whole reason why strtoint can work without var paramaters is that it
throws as exception. You can only write e:=a(b(c(inttostr(d))) if you
don't need to check an error condition.
If you have to check for the error condition, you can just as well use a
var parameter. In short:
x:=strtoint(s);
if (s'0') and (x=0) then
{handle error};
e:=a(b(c(x));
... is no improvement over:
val(s,x,code);
if code0 then
{handle error};
e:=a(b(c(x));
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.
So, if you want to write e:=a(b(c(inttostr(d))); you have to pay the price
for exception handling.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unreachable code warnings
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
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 the compiler generating too
much noise.
The compiler will be used in different ways by different people for different needs. Thus,
viewpoints will differ ands that means that discussions about the pros and contras of a specific
warning can be endless. The way out, I believe, is an infrastructure where individual warnings can
be put on and off, like gpc and gcc have, e.g. see
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Warning-Options.html. I believe I heard that it is on
the todo list ?
Regards,
Adriaan van Os
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 you can query the values via RTTI. BTW: Is that something similar to what VB6 (I think) does. I remember from many years back that when you selected a property to edit, in the bottom of the Object Inspector (whatever it was called in 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. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 executables ;-). Later we can invent new switch to control inclusion of such extended rtti into final executable. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 descriptions in your final executables ;-). IMO rtti is not strictly needed for this concept. It could also go the the ppu (and then you can apply attributes to more symbols) Maybe the problem is that I dont know what is ppu (yes, I saw such extension on my file system) and how to query that ppu from lazarus. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unreachable code warnings
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
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 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 the compiler generating too
much noise.
The compiler will be used in different ways by different people for different
needs. Thus, viewpoints will differ ands that means that discussions about the
pros and contras of a specific warning can be endless. The way out, I believe,
is an infrastructure where individual warnings can be put on and off, like gpc
and gcc have, e.g. see
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Warning-Options.html. I believe
I heard that it is on the todo list ?
Indeed it is.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unreachable code warnings
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 the compiler generating too
much noise.
The OP wanted to avoid a warning at a defined place in his code, because
he is sure that the code he wrote __in these lines__ is correct. So
being able to switch warnings on and off in the code would be easy to do
and very helpful.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extracting debug-information from fpc-executables
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 it ring a bell to anyone? + /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/fpcbuild-2.2.0 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64 /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex: Could not find DWARF-2 abbreviation 255 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/h2pas error: Bad exit status from /var/tmp/rpm-tmp.22914 (%install) Someone from Redhat helped investigate and solve the problem. There was one problem with rpm (https://bugzilla.redhat.com/show_bug.cgi?id=336951) which is fixed. 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 fpc. But I think I've heard some fpc-developers talking about this issue before, are the problems with file-names in the dwarf-debuginfo fixed? And do fpc follow the guidelines as in the bug-report? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extracting debug-information from fpc-executables
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 this output, does it ring a bell to anyone? + /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/fpcbuild-2.2.0 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64 /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex: Could not find DWARF-2 abbreviation 255 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/h2pas error: Bad exit status from /var/tmp/rpm-tmp.22914 (%install) Someone from Redhat helped investigate and solve the problem. There was one problem with rpm (https://bugzilla.redhat.com/show_bug.cgi?id=336951) which is fixed. But there is also a fpc-bug (https://bugzilla.redhat.com/show_bug.cgi?id=337051) Can you create a Mantis issue for this. 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 fpc. But I think I've heard some fpc-developers talking about this issue before, are the problems with file-names in the dwarf-debuginfo fixed? And do fpc follow the guidelines as in the bug-report? I need to reread the specs. IIRC I added the lineinfo according to my interpretation of the specs Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 It's FREE. Download it and get with the program! ;-) I bet you those two are MS Office users [..ducking and hiding..] Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extracting debug-information from fpc-executables
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 in a different manner. That could be a problem when building RPM's on a Fedora system. I got this output, does it ring a bell to anyone? + /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/fpcbuild-2.2.0 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64 /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/lib64/fpc/2.2.0/ppcx64: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/plex: Could not find DWARF-2 abbreviation 255 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fpcmake: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/fp: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir /usr/lib/rpm/debugedit: /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/rmcvsdir: Could not find DWARF-2 abbreviation -1 extracting debug info from /var/tmp/fpc-2.2.0-7.fc8-root-kojibuilder/usr/bin/h2pas error: Bad exit status from /var/tmp/rpm-tmp.22914 (%install) Someone from Redhat helped investigate and solve the problem. There was one problem with rpm (https://bugzilla.redhat.com/show_bug.cgi?id=336951) which is fixed. But there is also a fpc-bug (https://bugzilla.redhat.com/show_bug.cgi?id=337051) Can you create a Mantis issue for this. Done: http://www.freepascal.org/mantis/view.php?id=9965 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 fpc. But I think I've heard some fpc-developers talking about this issue before, are the problems with file-names in the dwarf-debuginfo fixed? And do fpc follow the guidelines as in the bug-report? I need to reread the specs. IIRC I added the lineinfo according to my interpretation of the specs If you need help, the person who submitted this bug-report has a lot of experience with the Dwarf-format. He send me a mail in which he said that he likes it that he now has a second compiler which produces Dwarf-info. It's usefull for testing, and he found a few shortcomings in the elfutils library with it already. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 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. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 option. (BTW.: Open Office does write PDF without any plugins or external programs.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.) Except, if you want others to extend / adjust / improve your document. In that case PDF is worthless. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 read and write standard conform files (i.e. Open Document ODT). 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. Then why have a standard, if no-one is going to use it ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 installed. Valid considerations, but regarding this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.) Oh, come on. An OpenOffice created PDF would have had about 30K+ size after base64 encode. :P And that for data which could most easily have been provided as plain text inside the mail: -- 8 -- PropertyDeclaration ::= PROPERTY Identifier [PropertyInterface] [PropertySpecifiers] [Directives] PropertySpecifiers ::= [ ... ] [ ... ] [ATTRIBUTES AttributesArray] AttributesArray ::= '[' (AttributeDeclaration [, AttributeDeclaration]) ']' AttributeDeclaration ::= string':'string Declaration examples: TmenuItem = class(...) ... property Detachable: Boolean read FDetachable write SetDetachable attributes ['widgetsets:qt,gtk,win32', 'implementor:Vasya Pupkin', 'creation-date:01.01.2007']; ... end; TxxxDatabase = class(...) ... property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attributes ['engines:firebird,oracle,sybase-asa']; ... end; -- 8 -- Of course, the syntax highlighting is now missing but as the intended target audience are the developers and not managers, the missing blue won't lose you information, I'd say. VinHow big is that whole mail now?zent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extracting debug-information from fpc-executables
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 fpc. But I think I've heard some fpc-developers talking about this issue before, are the problems with file-names in the dwarf-debuginfo fixed? I think I fixed this in r8417 (r8584 in the fixes branch), apart from possibly the trailing slashes. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
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 switching a switch when calling the assembler? No, thumb assembler code is different from generating normal assembler code. You need serious code generator modifications. Even worse. Thumb is completely different instruction set with different number of registers. Completely new code generator is needed for thumb. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
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 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 memory power than ARM code. Source: Steve Furber, ARM system-on-chip architecture. So in my case, I won't touch Thumb code ;-) Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
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 memory power than ARM code. Very valuable information ! OTOH, there now are processors that only do Thumb but not 32 Bit ARM code (Cortex M). There is no Linux or WinCE for those yet, do supposedly nobody wants TP for them, but in the future that might be viable. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 be a big problem. The good thing is that no new language feature is needed. regards, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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. Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword. Lets discuss this proposal. What is the purpose: extend rtti (or another structures that can be accessed at run time) with list of user defined Name=Value items. How it can be used: since it is generic solution different tools can use it in their own way. For example in LCL we can use attribute 'widgetset' to define widgetset specific properties and show such properties on another Tab of Object Inspector or with different colors (or show hints and so on). I see no problem with this proposal from a language point of view. The only problem is the storage. Your 'runtime access'. I don't think it belongs in the RTTI. RTTI ends up in the binary, and we get already enough complaints about binary size. A switch to leave it out is not really a good solution, it shouldn't be in there in the first place (apart from the technical feasability) Also, the only place where this extended information is useful, is in the Lazarus IDE (or any other IDE) Therefor I propose to simply write it to the .ppu file, or - like the resource strings - to a separate file: one per unit. (a .ppi file: pascal property information). 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 make a copy of this unit in the packages, and extend it with some search methods/classes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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/rtc/fcl ones, althougth that shouldn't be a big problem. The good thing is that no new language feature is needed. 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. BUT, I know what how the code work and I want an easy way to add small hints to that code (and this hints must be understanded by IDE). Moreover that hints can be used later by help/documentation tools when they will generate their output. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 more information to the user of LCL then what is on
the function parameters and other code parts.
This information can be: Works on the following widgetsets: X, Y, Z
But it could also be anything else desired.
Some code documentation systems work by parsing comments which go in
the source code itself, like javadoc, and that would probably make
things easier for you as you don't need to leave the code editor to
add documentation information, and shows an advantage of this
documentation system.
If we were using such a system we could have a comment like this:
{Function X
Description: blablabla
Widgetsets: win32 wince
}
function x()
begin
I always liked the comments in-code approach a lot better, but I doubt
that we will change now.
Particularly lazarus uses lazde to edit the documentation, which is in
XML files that can be outputed into HTML files. It's not particularly
easy to work with.
The help is already integrated into the object inspector, pressing F1
shows (or attempts to) show a url with the respective docs. From there
we could extract the widgetset information or anything else and then
it can be shown this in whatever way desired.
If our current documentation system is too hard an alternative idea
would be adding a hint to the IDE on the code.
Maybe:
procedure MethodX; {%widgetsets win32 wince}
This should be quicker and easier to implement then extending the ppu files.
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 achieve *is* documentation. You desire to pass more information to the user of LCL then what is on the function parameters and other code parts. Actually I need this to make lazarus ide more user friendly. For example to distinct unsupported by widgetset properties from supported, to show another hints for properties (if that hints named as properties attributes are defined). Docemntation generation is just an example of another application of this nice feature. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Odd question?
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 stems from the time that the compiler was not very good at inlining nor at removing stack frames. I would probably be best to simply remove all assembler implementations of Odd() from the rtl so the generic Pascal version is used instead (which can be inlined). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
(...)
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
duplicated parser code...
-Flávio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 release mode. For
example the following compiler directives could be put at the begining
of the LCL units.
So you pay for what you use, and don't have to pay and don't pay for
what you don't use.
{$IFDEF DEBUG}
{$ANNOTATION+}
{$ENDIF}
{$IFNDEF DEBUG}
{$ANNOTATION-}
{$ENDIF}
By the way why not adopt the Delphi attributes's syntax instead of
creating a new one with
incompatibilties ?
Personaly I could use it in the WST to declare entities's
serialization style (attribute
properties, embedded array, external elements names ...), SOAP
operation encoding (
litteral or encodded ), SOAPAction
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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; [OperationContract] function Subtract(a, b: integer): integer; end; -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 SetTransactionModel; ... end; That doesn't look like language syntax to me, more like a comment? Isn't property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attribute Engines: List = 'firebird,oracle,sybase-asa'; much more logical ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 FtransactionModel write SetTransactionModel; ... end; That doesn't look like language syntax to me, more like a comment? Isn't property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attribute Engines: List = 'firebird,oracle,sybase-asa'; much more logical ? Indeed. Exactly my point. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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
write SetTransactionModel;
...
end;
That doesn't look like language syntax to me, more like a comment?
exactly my idea, even more since [{ are pretty similar
otoh, it looks a bit like a pragma now
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 parametters, method or procedure, module... ), I think it is a reasonable syntax; It IMHO isn't, since it is prefixed, like C#, while Pascal (AND variants) usually have directives and modifiers AFTER the keyword. __cdecl int func(void) vs function func:integer; cdecl; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 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 features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 implementation; it departs rather far from what Wirth designed). While .NET features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. I have a great respect toward FPC devel team. And I do anderstand and respect that FPC team do not plan to be compatible with Delphi.Net. 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. -- Inoussa O. I tend to agree, but Borland has neglected Delphi for so long that I really wonder if anything above Delphi7 (or even D5) is truly relevant... -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 make a copy of this unit in the packages, and extend it with some search methods/classes. I dont like idea of maintaining code more than in one place. The best way is to create sone unit to read/write that ppu files and use it in all places: in compiler, dumppu and later in lazarus. Of maybe it is not possible (for fpc I am simple user)? Btw, is proposed syntax need modification or it looks ok? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: fpc-devel Digest, Vol 40, Issue 20
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. Therefore it is more compatible. When you upgrade to the real sysutils after you decide your application has grown to be such bloatware that it won't matter.. then at least now your inttostr will work with sysutils and compactsysutils.. plus you will have two error checks.. the exception and the manual verification. Furthermore, if you forget the try/except, at leas you will have real logic checking. I rarely see people use try/except around strtoint in delphi code (maybe just sloppy programmers). However, that being said.. I think checking for if s'0' is kind of a cludge.. but so is checking using ugly val with Var params either way. Val is more obvious to the programmer and would be recommended for airplane/rocket ship programming where it is critical errors are within the contract. Actually, that is something I brought up in an article recently about error contracts being forced by the compiler using Tuple's as function resutls, but anyway that's off topic. Floats, however would be much harder to check for.. 0.00 0.000 etc. and maybe a parser would have to be added to check the float first for valid input. But if we do not agree to make the StrToInt functions part of fsutils or tinyutils or intutils or convutils then I'm fine with this.. we can just tell people to use Val. At least we have all the other functions to put into fsutils/txtutils such as CompareText, WrapText, ExtractFilePath, and lots of others. i.e. strtoint isn't a show stopper either way. Also some from the StrUtils? Since strutils puts sysutils in uses. Maybe we make one called txtutils or textutils.pp for things like comparetext/wraptext/strutils ones? Or just tinyutils.pp with tons of functions all in one namespace? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 introduced in D7) Yup. D7 introduced the Delphi Language and killed Object Pascal, perhaps because of the .net stuff. -- Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
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 features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. I have a great respect toward FPC devel team. And I do anderstand and respect that FPC team do not plan to be compatible with Delphi.Net. 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. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
